Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

Does Agile need Architecture to be successful?

EA Learning — Wed, 24 Jan 2018 03:21:00 GMT

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!” I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise. Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design
Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level, SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe, this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long-term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Business Analyst - The ONE – Part 4

RANGA — Mon, 25 Apr 2016 12:59:00 GMT

We saw about the problems and the ways of defining a solution to those problems in the last article. Also, I had mentioned that when a problem arises, there is a need for the business to resolve that problem. So, what would be business needs? It again depends on the problems which they face. By definition, Needs are desires of the project customer that focuses on a business problem; its fulfillment is strategic to organization goals. In IT world, it is to identify and define why a change to an organizational system or capabilities is required.

Determining specific business needs is the main objective which as a business analyst you might need to clarify and understand it completely in order to be most effective, as the solution is driven by those needs and your project will also be evaluated based on those.

Most of the business needs arise due to the common issues such as loss of revenue, customer complaints or a direction towards which the entire organization need to move, like regulatory bodies defining a common rule which need to be followed by all the organizations. In our previous example on the problem faced by the hotel business on customer smoking, the main business need was to eradicate this particular problem which was resulting in bad customer experience and due to which there was a revenue loss. So, without someone acting as an analyst, the business wouldn’t have a compass or a map to guide them in resolving such issues.

As an analyst, here you are in the role of defining the needs from the business point of view (remember the initial writing, where I mentioned the different type of business analysts, this role is more from the person who is working from business side to provide the details to the technology or provide solutions by themselves), you are expected to define the business needs considering the following points

1. How then different stake holders like end users, front-line workers, management, vendors or any other stake holders / different business units define the perceived problem?

2. The areas which are affected by the problem, like client retention, gross/net revenue or development budgets etc.

3. Feasibility, drawbacks and benefits of suggested solutions to eradicate the mentioned problem, like in terms of manpower, revenue, capacity.

When you say you need to define a business need, you can represent that need in terms of multiple ways. When there is a technological improvement required based on your business need and when you are trying to define the business need for technology to understand, don’t define in such a way that what you want system to do for your need, define what your expectation from the need for your business improvement. As when it is defined in terms of what business need is that time, the change in the business based on that need is also identified. So, think and specify your needs in terms of new, value-delivering processes and opportunities like how you want to work in the future, the process steps, information needs and process logic. Then you'll have systems that align exactly with your needs.

The business need is not typically a stand-alone deliverable or document. Instead, the business need is a very high-level business requirement that should be included in the business requirements document or business case for your proposed project.

In traditional method of defining a need, an analyst will define the need in terms of his requirements, corresponding document known as Business Requirements Document and all the details of the changes that are expected shall be incorporated in to one single document. In modern trend, everyone being agile in their process, the needs are split in to individual stories and each story explaining a specific requirement for that need. Since the story is defined by the end user, it is again termed as a User story and a model user story will look like below

As a hotel manager, I need to have smoking zones in my hotel so that I can have a better customer experience and increase in revenue because of that.

To define the business need and understand the desired outcome, try brainstorming with end users and personnel, analyzing the current ways the company does business to identify weaknesses, interviewing subject matter experts, and holding focus groups for stakeholders and users. Analyze every aspect of the business, even those you aren’t confident are part of the issue.

So, what’s next!!! Yes, now we have “opportunities” to explore further :)

Things to know before you start your BA career

Bharat Mamtani — Mon, 25 Apr 2016 02:18:00 GMT

Now when I am already a successful BA since many years, I would like to share few moments with everyone.

During my first months as a business analyst, life was filled with a sort of inner turmoil. Even though I had books on how to write requirements documents, had received individual mentoring on putting together use cases, and had a trusted set of templates to follow, there was something uncertain about how the business analysis process would actually unfold.

I found myself making a lot of mistaken assumptions about what to expect, having those assumptions prove to be unfounded, and then needing to find ways to adjust and course correct. Looking back, there is nothing unexpected about my experiences, except that they were unexpected to me at the time.

Knowing that many of you are just getting started, today I am sharing 4 of the things I wish someone had told me when I was just starting out in my business analysis career.

Need to set expectations early and often, and then again and again and again…

As a business analyst, it’s not uncommon to receive too many assignments, tasks that are outside your bailiwick, or unreasonable deadlines. I was surprised to find myself constantly explaining what I was doing, why it was taking so long, and what could be expected of me over the coming weeks, even though I didn’t always know what the next week would look like!

I also found that deadlines would seem reasonable but became overly optimistic when I didn’t hear back from stakeholders in a timely manner, couldn’t get time on the calendar with a critical stakeholder for weeks at a time, or encountered unexpected issues.

I learned to continually clarify my role, communicate about what would be done when, and seek feedback to be sure I was meeting expectations.

Getting information could be a little painful

Early on in my career, I naively expected unlimited access to stakeholders and their unhindered involvement in and passion about my projects.

The reality was much different. My stakeholders had multiple projects, conflicting priorities, and too much to do. Even when my project was important to them, it could still be difficult to get the information I needed in a timely manner.

Over my career, I learned to be a bit of a squeaky wheel – a very polite, diplomatic, and conscientious one – but squeaky nonetheless. My projects started to move more smoothly and I met my deadlines with less angst.

Although being the requirements author, you aren’t the requirements owner.

I love to write and I love to write requirements. But I could get so caught up in writing and documenting and modeling that I would take on more ownership than was prudent. This would lead to a lack of buy-in from critical stakeholders, which could translate to unexpected changes late in the project.

The reality is that we absolutely need stakeholders to take ownership of the content going into the requirements document, even as we author that document on their behalf. And yes, they are likely to resist reading, reviewing, and providing feedback on requirements.

I learned that providing early, incomplete drafts that were clearly imperfect would help stakeholders see that they could add a lot of information and clarity into the requirements. I also learned to be very specific about the status of any given deliverable when sending it out, and equally specific about what I was asking of my stakeholders of this document at this time.

Dealing with issues professionally would take a new kind of finesse

I’ve always been a proactive person and a bit of a whistle-blower. When a new issue surfaced, I would signal the alarm, rally the troops, and facilitate a problem solving meeting.

However, discovering requirements is a gradual process of gaining clarity and minimizing ambiguity. At a certain point in time, every requirement was once an issue. Business analysis surfaces so many issues that you can’t possibly resolve all of them immediately.

With experience, I learned to blow the whistle more softly, keeping everyone informed about what was surfacing, but not unnecessarily alarmed. To keep the requirements process moving forward, I also learned to take ownership of the issues that surfaced inside of the requirements, and make more decisions about how to resolve issues and which options to choose or recommend.

Now that you know what to expect

Now that you know what to expect, perhaps you won’t be as caught off-guard as I was during your first days as a business analyst!

Happy Analysis !!!

Business Analyst - The ONE – Part 3

RANGA — Mon, 18 Apr 2016 12:57:00 GMT

Till now whatever we have seen was more from a bank point of view on few of the roles and responsibilities of a business analyst. Let us see on day-today what a business analyst might be doing!!!

Before understanding what business analyst do, let us understand why any business need an analyst. By definition, an analyst is the individual who analyze on any given topic, he is the one who examines and reviews the data or information or any specific area, like financial analyst look in to the economic and financial information associated with the stocks and securities so as to provide suggestions for the organization on investing on those stocks/securities. So, what exactly these individuals are doing for the business, they are helping the organizations to identify the problems, opportunities and needs and provide solutions for the problems, help in grabbing the opportunities and implement the changes that are required to satisfy the needs. This is the one of the many reasons why any business needs an analyst. Now that we know why business needs an analyst, you would also have figured out what could be the roles & responsibilities of them, yes you are thinking right, it changes according to the business need.

Let us concentrate on these problems, needs and opportunities and accordingly try to see what may be required for an analyst to do in such situations. All these three terminologies are co-related. In every problem faced by business there is a need for them to solve that and it creates an opportunity for an analyst to pitch in to resolve the problem. All business, whether small or big, faces issues/problems. Depending on the type of the problem, the solution needs to be arrived.

Let us consider a simple example of a problem in a hotel business, assume that the problem is smoking and because of customers smoking in common rooms, affects other customers, who don’t appreciate the smoke causes low customer satisfaction. To overcome this simple problem, an analyst works on identifying the problem on customer dissatisfaction so as to provide a solution. First he need to figure out the problem, this can be done by various methods, however let us assume he already identified this problem of smoking based on customer response to the satisfaction survey he conducted. Now he need to write down the problem statement as a first step, a best problem statement post identifying the real problem would be something like below

The problem of customers smoking in our rooms affects other customers, who don’t appreciate the smoke and smell, and our housekeeping staff, who spend significantly more time cleaning smoking rooms versus nonsmoking ones, the impact of which is low customer satisfaction, reduced occupancy rates, and increased cleaning costs. A successful solution would be to eliminate smoking and smoking effects from our hotel rooms and readdress those impacts.

To arrive at the solution, he need to do the following

1. Identify the root cause of the problem, which in our example is customers smoking.

2. Identify as many as solutions possible, i.e. identify multiple possible solutions which can resolve the problem

3. Prioritize potential solutions, meaning identify which you foresee as an acceptable solution for all.

4. Make a decision to select the best one out of the identified solutions. This can be a collaborative effort along with the stakeholders of the problem and as well as the business owner.

Post identification of the solution, it doesn’t stop there, assign responsibility and set a measure / target to ensure that problem is not repeated again.

Whatever I have told, even though generic, is applicable for any problem in any of the sectors where technology is involved. So, as a business analyst, you always need to identify the root cause of any problem and try to fix that so that it is not repeated again.

So, can we identify the best possible solution to the above problem? :)

What we are left with to ponder around, yes, you are right, needs and opportunities … let’s wait for few more days :) ...

Business Analyst - The ONE – Part 2

RANGA — Tue, 01 Mar 2016 13:55:00 GMT

Now, I am a BA. My role of doing the routine operational work is no more there. Now I am in to the mode of asking questions. So, what are the questions I should be asking? How am I supposed to interpret the answers? How do I build my knowledge on the process based on these answers? How can I contribute to the improvement of the process? These are few questions, which came to my mind when I started this role.

Note that I am writing this article more from technology and banking point of view. However, I will try to generalize the same in future articles.

I had joined a technology organization after working for many years in banks, however was still supporting a bank as a business analyst on behalf of this technology organization. As I mentioned earlier, my understanding on the role of a BA who is working for a Bank is to ask questions so as to analyze the process happening around the bank and provide solutions for the process improvements, either technological improvements or operational process improvements. With this understanding, I started working for the technology organization; however things were slightly different out there. When you are part of a technology team from the bank, your main goal becomes providing solutions towards enhancing the systems that are being supported by the technology teams or support for enhancement of the systems used or developed for the Bank, either it is in house (built by the bank’s technology team) or it is an external system (supported by another technology organization). So, the questions you ask shouldn’t be restricted only to improve the process followed in banks, but also should be from the supported systems point of view, i.e., those questions should also be more from technology point of view whether such process enhancements are feasible from the existing system point of view or not. This would be quite challenging, as you are not only acting the roles of a business analyst in asking questions to analyze the processes alone, but also understand the systems used so that you can translate the business requirements in to functional specifications for the understanding of the developers to enhance the system. Confusing? Or Interesting!!!

To avoid confusion, if any :), let us see understand the difference in the activities performed by the business analysts in these banking and technology sectors. Let us say,the Bank uses two different systems Alpha & Beta for one of its processes, Alpha being an external application supported by a technology organization & Beta being an in-house application developed by the technology team of the bank. Also, assume Oliver is a business analyst who is working for the Bank, Mark is a business analyst working for the technology organization & Bob is a business analyst who is working for the technology team of the bank.

For Oliver, since working for the bank directly as a business analyst, his role is more to understand the business process and provide process improvement ideas, so he creates requirements that need to satisfy the business needs on behalf of the bank, the documentation created for this purpose termed as Business Requirements. Note that he will not be concentrating on whether for the process enhancements, which systems need to be enhanced. He will more be interested on how those business requirements can be put in place for business efficiency, so he will wish to see the end results by testing those requirements. So, the questions he will be asking business will be more from this point of view of whether the suggestions he is providing to enhancing the process, results in business benefits.

The roles of Mark & Bob would be the same from their respective applications support point of view; i.e. they need to analyze those business requirements given by Oliver and come up with solutions for enhancing their respective systems Beta & Alpha. So, what they will do is translate those business requirements in to the language in which developers can understand and enhance their respective systems according to the requirements, the document which is created for this purpose is generally termed as Functional requirements. For this, they need to understand the business requirements thoroughly, until they are very clear so that they can provide solutions on how the requirements can be fit in to their systems. How they understand the business requirements, is again by asking questions, but these questions would be more not only from business point of view, but also from technology point of view, like whether the business process enhancement suggested really helps business or not? How much efforts required for them to enhance the system? Will that enhancement really be worth to do?, the results of these questions, rather the answer to these questions will result in identifying the impact to their respective systems and the supporting stake holders, if any, which is being termed as “Impact analysis” or “Functional Impact Analysis”. They also need to support the development team in terms of testing the requirements before them handing over the product to Oliver for him to test the final output. This testing done by the testers, with the support from Mark & Bob, is termed as SIT (system integration testing, performed by technology with the help of technology BAs) and the testing done by Oliver along with the end users to ensure that the final output meets the business requirements which was given initially is termed as UAT (User acceptance Testing, as Oliver is the business representative, who is acting on behalf of the user). Also, note that the roles of Mark & Bob will slightly vary depending on the respective systems they support.

I think I have introduced more terms now to make it more confusing, relax, its simple. So, what you think? Are we done with all the roles and responsibilities of the BAs!!! No, please wait for the next article to come, as we have a long way to go :) …

Business Analyst - THE ONE - Part 1

RANGA — Thu, 11 Feb 2016 13:49:00 GMT

Business Analyst – First time when I heard this word while working for banking operations, I was really curious to know more about the role behind this word. One fine day, I was introduced to a person by my senior manager and was told that I need to explain him on the processes which we were doing in the banking operations. I initially thought this explanation is going to be a cake walk for me, as working monotonously for more than 6 years on the same products and operations team and teaching being a passion and almost all the new joiners have been trained by me, I was thinking that explaining the person wouldn’t be a big challenge. Conversation began with me explaining him on the entire operational flow of funds transfer and mutual funds. Later, he shoot me with his questions (there came the darker side) on the end to end flow or rather life cycle of a funds transfer or Mutual funds. That was the time, when I realized that I have limited myself to a certain level of learning, thinking that it is the whole process by itself and I have way more to learn than I could imagine. I was so fascinated by the way he was asking queries to me, as none of those, I could answer at that moment, but answered with a smile that I will let him know by the next week, hearing this, he left for that day. Out of curiosity, I asked my senior manager, who was that person who was literally interrogating me with his questions to which I was totally blind-stuck. He said he is a Business Analyst who has come for understanding the entire process that is being followed, so as to provide ideas on improvement of the processes. Trust me, that was the first time, I know that even Banks hire Business analysts.

Next week, I was well prepared to answer all his queries he asked me the previous week, I had went beyond my level to understand the complete flow touching base with front office, middle office and even within my operations team. I could answer all the queries he asked, as I myself had understood the entire flow of funds transfer and Mutual funds, not only from operations point of view, but the end to end life cycle. He was happier that he got all his requirements. This time I asked him directly “Sir, what should I do to become like you?” he smiled and said “You have already become one when you were able to answer all the queries I asked, as you have the answers, it is just that you need to convert your answers to questionnaires, so keep on asking “How”, “Why?”, “What” & “Where” like “How sooner you can complete this if you do like this”, “Why we need this process”, “What is the risk the Bank would face if this is done this way”, “Where is the data coming from””. That was the day, when I started transforming myself from a role of a Manager doing routine operational work to a Business Analyst who understands the end to end flow of everything across he was working, to put it in the Matrix words, I became the ONE who already know the answer to the question which I am going to ask.

Now that I have become a business analyst, thinking that only asking questions to the answers which I already know will make me a successful one in that field, proved later that my assumption was completely wrong and there is way more to be done on that role than what I was thinking.

So, let’s see what you are expected to be doing practically while working as a business analyst in a next article

Research: Roles and background before becoming a Business Analyst

Trividh Patel, CBAP — Mon, 11 Jan 2016 02:28:00 GMT

I am pleased to share the analysis of a Qualitative Survey to understand the backgrounds of Business Analysts (BAs) and the roles they have held prior to becoming BAs. This survey was conducted as an informal poll on LinkedIn. The numbers of participants are over 250 and hence are statistically significant to infer.

Inferences

Developers/ Programmers are the highest to become BAs (most of them after becoming a Tester, QA Analyst, Systems Analyst, or Project Manager).
Business side Subject Matter Experts (SMEs, including end-users) are the 2^nd highest to become BAs (some of them after becoming Tester or Project Manager).
Project Managers and Systems Analysts are the 3^rd highest to become BAs.
MBA and Bachelors degree in Information Systems has helped to directly become a BA.
People with other roles/background that have become BAs include
- Testers and QA Analysts
- Application Support and Customer Support
- Sales, Marketing and Relationship Managers
- Data Analyst
- Technical Writers (including those working on proposals)
- Technical SMEs (Implementation/ Configuration Analysts)
- Project Coordinators

Conclusion

People from diverse backgrounds (technical, business, support etc) and roles have become BAs but there is no one particular path that can suit all, hence your own efforts and hard work will get you where you want.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

Dealing with Difficult Stakeholders

sbowling999 — Sun, 27 Jul 2014 20:50:00 GMT

The question will undoubtedly arise during your tenure as a business analyst, ‘How do I manage a difficult stakeholder?’

I once encountered a stakeholder, a very highly respected mathematician, who had developed an application based on a mathematical model of his weather systems. The algorithm was amazing. The application sucked. It was my job to:

1. Ensure his model used enterprise data so it could be shared amongst other applications I was helping develop and,

2. To either refactor and debug his application or port his algorithm to a new User Interface so it was available to a larger user group.

Long story short, he hated me. More accurately maybe he hated the idea of me. So what did I do? I elicited his feedback every step of the way. I made him a full partner in the change experience. But I also put my foot down and let him know the change was going to happen. I recognized that he was heavily invested in the application he had grown from scratch. The larger community wasn’t aware of his accomplishment. So I suggested he demo his application to a larger group of users. He got the opportunity to share his vision with the enterprise. People were amazed at the model and he received his just credit and some back slaps. But during the course of the demo he was also slightly embarrassed because there were technical issues and bugs that were apparent (as I knew they would be) which motivated him to embrace the improvement process.

It also helped to understand what was important to him and his own analysis process. Because he was the logical type I crafted my analysis plan to rely more heavily on statistics and fact based decision making. After showing him the error logs for his tool as compared to other applications for example, we agreed together that reducing the instances of error and downtime needed to be our joint #1 priority before we exposed the application to a larger audience. Because I always kept him informed, treated him as my primary stakeholder and never pulled punches, he began to see me more as his partner who could help him through the change process and bring his model to a much larger audience. For that to happen, he had to let go of complete control and we eventually repackaged his model/algorithm into an entirely new UI consistent with our other enterprise applications. Looking back, the only thing I would have done differently is put my foot down on Day 1 instead of Week 3.

It’s also critically important to find out the concerns of your most difficult stakeholder. In another example, I had a difficult stakeholder group who were code enforcement inspectors. You know the guys who condemn houses? As a group they were refusing to use their 2 year old mobile application. Citizen complaints raged as their investigation backlog grew. When their contractor mistakenly demolished the wrong house, the Mayor’s office finally decided to hire me as a consultant to improve their systems and processes. The workers grumbled and pushed back on requests for changes. I decided to select the least tech savvy, most senior vocal influencer and rode with him for a solid week. Every morning at 6 a.m. we met the crew for coffee at McDonalds. I donned work boots and shadowed him as he walked around in dark condemned houses in the worst part of town. We met the guys for lunch at the 7-11, conversed and I truly began to understand their challenges and why they hated the old application. I also understood that the fear of using the technology was elevated due to a general lack of experience with web technology. At the end of the project this ‘difficult stakeholder’ helped me teach the training course and volunteered to be the ‘go to guy’ for all other inspectors! Listening and putting yourself in the stakeholders shoes really works.

So here are my steps to better stakeholder relationships.

Identify key stakeholders who can throw a wrench into your project’s success. Key stakeholders may be members of the executive or management team. They could just as frequently be informal team leaders or members who influence others. Ensure you are proactively nurturing those relationships.
View them and treat them with the importance a key stakeholder deserves. Nothing turns a stakeholder into hostile mode faster than getting a cold reception and the sense that his opinions are not valued.
Take the time to truly understand their perspective and concerns. Put yourself in their shoes. Not only will you be investing in the relationship but you will likely also learn important information that can help craft your analysis, deployment, training or support plans.
Ensure there are ample opportunities for your stakeholders to provide feedback in a setting that is most comfortable to them. Some people aren’t comfortable sharing in a group setting or JAD session.
Be sure to incorporate their feedback into the overall plans so their concerns are addressed.
Recognize that change doesn’t happen overnight. Employ an appropriate change management strategy.
Create opportunities for your difficult stakeholders to show leadership and excellence. Everyone wants to be recognized for their accomplishments.
Engage them to help win the buy-in of other team members who sit on the fence. Nothing ensures your project’s success like having the team leaders champion the change.

The success of a business analyst depends heavily on the relationships he builds along the way. Pay attention to the key stakeholders and remove this obstacle so you can get on with the business at hand.

How Do I Become A Business Analyst?

Trividh Patel, CBAP — Wed, 05 Mar 2014 05:26:00 GMT

This is one of the most frequently asked questions I have encountered ever since I have started training business analysts. Before exploring ‘how’, one should ask ‘why do I want to become a business analyst?’ Is it just because every talented individual want to do it, or you want better opportunity, or for better salary. In my opinion, if you have the necessary skills and business analysis is something you would love doing, only than you shall be a successful business analyst.

The purpose of this paper is to provide practical guidance on skills that you need to acquire to become a business analyst. This paper also highlights certain myths on this subject.

To become a business analyst, you need to

1. Improve your communication skills

‘You can’t be business analyst if you can’t express yourself’.

The role of business analyst mandates excellent communication skills including oral, and written, and much more. A business analyst is expected to effectively express ideas, information and have ability to make oneself understood. S/he should also demonstrate good vocabulary, excellent listening and presentation skills.

Demonstrating such skills starts from your resume and gets noticed in your job interviews. So, if you think that you are lacking in any of these aspects, you should consider seeking professional help and improve.

2. Acquire business knowledge

‘You are wasting everyone’s time if you do not understand what they are talking’.

The role of business analyst also requires understanding the business domain and industry (banking, insurance, telecom etc), and/or solutions (CRM, ERP, COTS products etc) in which s/he is expected to be working or desire to be working. A generalist business analyst may be expected to work in multiple domains but s/he is still expected to have the ability to talk to specialists from that business domain and industry. A specialist business analyst is expected to have thorough knowledge either in the business domain and industry (many times referred as Domain Consultants) or in solutions (many times referred as Functional Consultants).

This knowledge can be learnt theoretically but the practical knowledge can only be acquired by working in the core industry or on projects. So, if you already have experience and knowledge on certain business domain and industry or even solution, make sure you highlight it on your resume. Also, the organization where you are seeking role as a business analyst may or may not give importance to this, or may even relax this to certain extent depending on their requirements. So, depending on where and what area you want to work as business analyst, you need to evaluate appropriate courses that provide such knowledge.

3. Learn business analysis techniques

‘What value will you deliver (as a business analyst) if you can’t define problem, synthesize solution and communicate it to make everyone understand it’.

A business analyst needs to understand people’s concerns and capture their requirements to address their business problems. S/he also needs to specify and model these captured requirements using appropriate business analysis techniques for further analysis, design and implementation of the solution (which may include software applications). These skills are required irrespective of the business analyst role (generalist vs. specialised) or the business analysis approach (waterfall vs. agile). The techniques used by a business analyst to carry out above tasks include elicitation techniques such as interviewing and requirements analysis techniques such as process modelling, business rule analysis, use cases and scenarios, data modelling, non-functional requirements analysis etc.

Most of the organization where you would seek role as a business analyst would expect an experienced (if not, at least trained) person on these techniques depending on their project requirements. So, if you already have experience and knowledge on these techniques, make sure you highlight them on your resume. These techniques cannot be learnt by just reading books or from internet; you need a good mentor to give you a jump start. So, you must identify and learn from a professional mentor who can provide you such knowledge.

4. Enhance your analytical thinking and problem solving skills

‘You can’t be termed as “the analyst” if you don’t have analytical and problems solving skills’.

Skills such as creative thinking, learning, problem solving, decision analysis, ability to see the big picture etc are all required to be an analyst.
Some of these skills cannot be taught but can be consciously enhanced over period of time by solving puzzles, participating in debates and group discussions etc. These skills will help you not only during your job interviews but also while working as a business analyst.

5. Improve your interaction skills

‘It is not only analysis but also about leading and working with people’.

A business analyst is also expected to have good facilitation, negotiation, and leadership skills and at the same s/he is also expected to be a good team player.

You may refer self-help books and articles on leadership, team work, facilitation and negotiations. In your job interviews, you may also be evaluated against these qualities.

Myths

1. To become a Business analyst, you must have a technical (engineering) background

Business Analysis work is (and should be) independent of technology. BAs are not required to have in-depth knowledge or experience in programming, database, networking, etc. It is wrong to expect technical skills out of BAs. It is nice to have technical background as it will help a BA to talk to development team but not must have unless the work is that of a Systems Analyst (who has some overlap with BA roles and responsibilities).

2. To become a Business analyst, you must have an MBA qualification

It is not MBA degree but the skills which are generally found in an MBA helps him/her to become a business analyst. MBA's are expected to have good communication, presentation, interaction, analytical and problem solving skills so they are natural candidates for the role of business analyst. So, a full-time MBA (or even part-time) from a reputed management institute or university helps to get into business analysis relatively easier than without an MBA but a non-MBA too can become a business analyst if s/he has all the needed skills.

3. To become a Business analyst, you must know various business analysis modelling tools

As a business analyst, you should first focus on appropriate business analysis techniques and than on modelling tools. Modelling tools may improve your productivity and efficiency but cannot replace your expertise. After mastering various techniques, you will be in position to compare and select appropriate modelling tools based on your requirements.

Glossary

CRM is the abbreviation for Customer Relationship Management. It entails all aspects of interaction that a company has with its customer, whether it is sales or service-related. It involves using technology to organize, automate, and synchronize sales, marketing, customer service, and technical support.
ERP is the abbreviation for Enterprise Resource Planning, a system that is used to manage and coordinate all the resources, information, and functions of a business.
COTS is the abbreviation for Commercial off-the-shelf, are the pre-built software or products that are commercially available usually from a 3'rd party vendor, and are alternatives to the in-house developments.

What do you do?

Pjbussol — Mon, 18 Nov 2013 23:14:00 GMT

“So, what do you do?” It’s quite probably the question I most dread being asked. It’s a fairly benign question but as a Business Analyst I feel compelled to assess and understand what I am really being asked before attempting to provide an appropriately pitched response to my inquisitor. I find myself scrambling for the right words whilst my inner-voice is assuring me that whatever answer I give will most likely be met with confusion and probably even a little irritation.

“I am a Business Analyst” I awkwardly mumble – blushing out of embarrassment for the both of us – whilst preparing for the inevitable follow-up question…. Don’t get me wrong, I love my job and can passionately talk about it. The problem is, unlike a Project Manager, for example, the role of a Business Analyst is not clearly defined – You've got to love the irony!

The Business Analysis Book of Knowledge (BABOK) includes a standard definition of what a Business Analyst does. However, every Business Analyst, Project Manager, Hiring Manager etc. will have their own understanding and set of expectations. The truth is I don’t do any one thing. On any given day I could be mediating a heated discussion between a solution designer and a CFO in the morning and in the afternoon ordering doughnuts for a design workshop (tip: a great way to prevent any future mediation!) Sure, a Business Analyst needs to be skilled in lots of things and may be accountable for producing this document or that document, but these things should not define us and are poor indicators of the value we bring to a project. Every successful project starts with an idea but what is ultimately delivered is often very different indeed. The idea matures and flourishes and it is the job of the Business Analyst to cultivate and manage this change. We navigate the project through its life-cycle. The Project Manager might be in the driving seat but we are certainly up there next to her, preempting bumps in the road, managing diversions and ensuring the passengers in the backseat continue to enjoy the ride. For me, being a Business Analyst is much, I imagine, like being a parent to a teenage son or daughter – we must be objective listeners, excellent negotiators, understand budgets, have a real grasp on finances and build strong relationships (sometimes with people we don’t necessary want to). We are protective, we are demanding, we are challenging and we are 100% invested in the success of our “babies”.

“So, what do you do?” it’s still a question that I dread being asked, but honestly, I normally just respond with “I work in IT”… That’s normally enough to stop any conversation dead!

Want to be an effective professional? Follow up!

Lee Grinberg, CBAP, PMP — Thu, 18 Jul 2013 17:34:00 GMT

Would you like to be perceived as effective? Want to succeed?

Make sure you follow up.

As a BA you are involved in several initiatives at different stages of development. What separates an average professional from an exceptional one is following up on tasks assigned to others on your projects.

I'm too busy, you say? I don't own the tasks, you say?

Well, like it or not the BA has the primary responsibility of making sure requirements are documented, verified, and validated. This involves input from many sources and it's imperative to get the information in a timely manner.

The benefits of following up include:

Your work will be done on time
People will not forget the assigned tasks
You will be perceived as effective

How will I find the time to follow up, you say? Build it into your daily routine.

When sending an email, flag your email for follow up at some later time. Most email programs have this feature.
When speaking with someone, send them an email summarizing the conversation and confirming next steps. Flag the outgoing email as a follow up item.
Most importantly, follow through and follow up when the email reminder comes up.

In Summary, following up will enhance your job by making you effective. Following up is easily done using your email program and having the discipline to act.

Good luck on your assignments!

Do you want stakeholders to trust you?

Lee Grinberg, CBAP, PMP — Mon, 03 Jun 2013 12:23:00 GMT

Do you want to be an effective BA?

The first step is to make the key stakeholders trust you.

As I wrote in my previous post it is the first step in establishing yourself when you're the only BA in your organization.

When I joined and sat down for my first meeting with the project team not only was I met with stares of hostility I was also leveled with questions regarding the need for my role (gasp!) The project sponsor and his right hand who was developing business requirements were feeling threatened and did not want to give up control.

So, how to make them trust you? Develop rapport and give credit!

First, develop professional rapport. Over a few months, I met with them to clearly establish my boundaries (writing functional specs) as opposed to stepping on their turf (business requirements) and to offer my help with clarifications whenever I could. I learned their business terminology and got my hands on as much system information as possible. In the process of developing rapport, I was also learning about the system and became a better BA. This went a long way to establish my earnestness and good intentions.

Second, develop a personal rapport. I got to know these guys pretty well. We had a few drinks, shared personal stories, and trust soon developed. I also asked them for help in navigating the organizational culture. When people help you, they trust you.

The final watershed moment that made them trust me happened in another project meeting. I was doing a presentation on the state of the project to senior management and when the time was right stopped and gave credit to the guys who started it and kept it rolling. I took no credit for myself. This completely established my good intentions.

So, what finally happened? These stakeholders and I have a great working relationship which outlasted the original project.

Feedback cycles, meet deadlines. NOT good bedfellows

theBetterBA — Sat, 08 Dec 2012 20:12:00 GMT

Its quite a feat of strength to pretend you don’t have any weaknesses. I don’t pretend to be that strong.

Its quite a bit easier for me to look for faults, gaps, misses, short comings, imperfections and details that spell out why something is not right.

Its a blessing and a curse.

Looking at my deliverables in this light is second nature to me. Seek out opinions. Get critique. Make your work better. Constantly strive to push yourself.

But how often is that process of seeking critique under as much scrutiny as our work? Is it not as important? The means by which we seek out advice, and how we incorporate it is a corner stone of our work ethic.

It is much further reaching than our current project or task. It becomes part of the mechanism by which we operate. Its how we interact. Its how we present solutions and spread a sense of ownership. Its how we build teams and get stakeholders working together.

Collecting feedback, analyzing risk, determining scope are all facets of our role that we bake it into our projects. Its what makes us Business Analysts, Project Managers and good at our jobs. Its second nature.

(Image referenced from Qualtrics.com)

Until recently, what I have failed to realize about myself is where my “Assumptions & Constraints” are not being considered when I write my own “System Requirements”. Where can I improve? What about me is a risk to the business? How can we neutralize that risk?

For example, a portion of me that is very nearly atrophied since college is the ability and respect needed to accommodate deadlines. What’s the solution? If we can take a look at ourselves, at our weak areas through the lense of a requirements document, we may have immediately obtained that objective view that is necessarily to address a business problem.

Looking through the Requirement Document Lenses at Ourselves:

Analyze ourselves and the situation to define the problem (the Root Cause); ask others for thier throughts too
Identify what success is going to look like (our Business Requirements) when we’re done
Outline how are we going to deliver that success story (our Functional Requirements)
Think through all the places our impact has reaches (use cases)
Add some limits and restrictions we’re likely to encounter when working through our problem (assumptions and constraints).

We could take this to a whole new level, and write out sample requirements – which I may yet do! – but it is enough to employ this objective tool that we use on our projects as a way to address our own business strategies.

How are we going to get where we need to be? What do we need to do to get there? What does success look like?

Going to be asking myself these questions for some time to come.

In the mean while, one of my own business concerns is the need to address my ability to meet deadlines. Its not as easy as it is to type it on your resume. It actually means something.

What is a deadline, really? Well, according to the Wiktionary:

deadline (plural deadlines)

A date on or before which something must be completed.

I must make this deadline or my boss will kill me!
(archaic) A guideline marked on a plate for a printing press.
(archaic) A line which doesn’t move.
(archaic) A boundary around a prison

The connotation around number 4 could prove to be a bit extreme etymologically speaking, but what does this definition tell us? Probably nothing we didn’t already know. Its a date. A date by when something is due by. Not hard, right? I pay by bills by a date, I get my car’s oil changed by a date, I go to the dentist by a date. Easy peasy.

Not so much. A deadline means so much more than how its defined. As a matter of fact, weare often the ones defining the deadlines. We define the deliverables. We define the dates. Its so much more than doing something by a date, its defining what needs done by when.

Need to ask ourselves about our deadline, to help define it for our circumstance:

What are some risk mitigation strategies for your deadlines?
Where does your deadline get communicated?
How to do you state your deadline?
How soft or hard is this deadline?
What is going to impact this deadline?
Is this deadline clear, or clear as mud?
What is expected at the end of the deadline?
How do you estimate your deadline?
When should you ask advice before giving your deadline?
When should escalate a concern about your deadline?

Communicating and escalating risks earlier is also a key component to meeting and estimating deadlines consistently.

Here is what NOT to do:

Provide a deadline in this format “I’ll have that to you sometime on Friday”;
Jump on the first distracting or more fun project thrown in front of you – any chance to do something else
Let scope creep out and destroy your project plan as that hard earned feedback rolls in;
Wait to escalate a problem until after you’ve run out of time

Here is what you could do:

Provide specific dates, and times
Communicate multiple dates – be as transparent as you can be; what is the ideal/ best case scenario? What is more likely to be delivery date? What is the worst case scenario? Express your concerns immediately.
Communicate as soon as you are aware of what will impact that will have on your plan to meet your estimated deadline
If you are unsure, ask for time to think about it, and get back with your estimate later
Include a confidence rating on how confident you are that deadline is likely to be met
Don’t be easily distracted from your original plan – escalate the question to someone who can see the bigger picture, your manager or director
“Communicating early” does not mean to wait to communicate when the deadline is slipping, it means to communicate as soon as you’ve identified something that may cause it to slip.
When the impact of an unplanned activity has equal priority, escalate the decision immediately. Don’t think you can make that call with out being the tiniest bit subjective – when we’re that close the project, we’re often too close to make the best call for the company.

It takes time to systematically approach a problem until its second nature. Thinking of deadlines, feedback and scope creep in terms of requirements feels more systematic, more error-proof, and more organized.

Good luck, and happy self-analyzing!

The Need for a Recipe

Dahlia Biazid — Thu, 13 Sep 2012 07:50:00 GMT

Everyone knows what use cases are and their use in the software requirements process. We all know there are many ways to write them: logical, physical, to describe a manual procedure or an automated procedure. The purpose of State Diagrams is well-known to everyone in the field. They help us define the transitional lifecycle of an object moving and manipulated on within a system. Data dictionaries are important to describe the elements of each data entity or class. And so on.

It is like a toolbox to choose from. I could use the hammer to bang on a nail (its original use), or to open something (an innovative use). In my requirements projects (or rather sub-projects form software development for that matter), I can use any or all of these techniques to analyze the system at hand. The question is when? What is the best strategy to employ these tools and get results most efficiently and effectively?

Nevertheless, this question did not seem answerable; even worse, it was not even asked! Instead, I looked around for a sample deliverable or a template to follow, with the hope that they would give me a picture to visualize and help me put the pieces together; and hopefully relieve me from the need to have a strategy. The tactic worked to an extent, but not completely. I still did not know for sure which step to make at each time I went to see the client or sit to think about the requirements plan. Only until the project was complete was I able to see the picture. So naturally, I took longer than I should to complete requirements; and the results were not as satisfactory as I as well as everybody involved wished for.

What was missing was the method, the strategy, the cunning of a chef who knows which ingredient to add and the exact timing and portion. What was really missing - and seems to be still missing - is the "recipe".

Breaking Through the BA Mystique

palvarez — Tue, 11 Oct 2011 18:13:00 GMT

You can’t work in IT and not have watched “Office Space.” I mean, it’s a prerequisite, isn’t it? It’s like being a developer and never having heard “Code Monkey.” It’s the type of movie where you sit and nod as you laugh, recognizing it is funny because it is true.

My favorite dialogue in the film is between Bob Slydell (one of the Bobs tasked with downsizing Initech) and Tom Smykowski (a targeted employee).
- Bob Slydell: What would you say you do here?
- Tom Smykowski: I deal with the customers so the engineers don't have to!”(paraphrased)

In many ways, that line summarizes the role of a business analyst. Or does it?

It sounds like a simple question: “What do you do?” It’s the second most important thing that is communicated between two people when they first meet. And in most cases, the response is rather simple.

Well, for a business analyst, the “what” can sometimes be difficult to explain. Following the words “I’m a business analyst” I tend to get wordy and I ramble on trying to find the right words to communicate what I do on a given day without going into the specifics of the project on which I’m currently working. Because, after all, it always depends on the project, doesn’t it?

It’s easier to define the “what” in a complex software system than it is to explain what a BA does. It’s what a certain manager I know once referred to as “The BA Mystique.”

Now, that “mystique” can sometimes serve us well. It’s what gets people to our meetings. My theory is that we often fill conference rooms and conference bridges with user reps, project managers, developers, testers, etc., simply because they want to satisfy their curiosity about what is it the BA does here.

For the most part, however, the mystique hinders us. It prevents us from focusing on the project scope, the requirements, and the task at hand, because we spend so much of the time allotted to analysis proving our worth to the team – defining our role and its benefits, explaining our methods, our document templates. Even after 15+ years, I still find myself defining my role with the onset of every project.

The BA Mystique exists across many IT organizations. It is often seen in managers who are not quite sure what to expect from their BAs. However, what is somewhat surprising is when that uncertainty comes from business analysts themselves. Only ask a colleague from a different company – no, scratch that, from a different department in your own organization (and sometimes even within the same department) – what he or she does as a business analyst.

It is a common theme at business analysis conferences, blogs, BA communities and organizations - many business analysts look at the work they are currently doing and wonder whether they fit the BA mold. The business analyst role has become a mystery to them. So, how do we clear things up? Well, it all starts with you and your desire to investigate, to learn.

Read. Resources for business analysts are more accessible now than they have ever been, in large part due to the increasing interactivity of internet sites. Business analysts and managers who have broken through the BA mystique are blogging about it, chatting about it, teaching free webinars, and writing books about it. All you need to do is a simple Google search on "business analyst" and you have access to about 56,700,000 references of knowledge and experience. But it is even easier than that! Browse through the Modern Analyst site and pore through the articles, discussions, and advice posted by your fellow business analysts. Read. Tap into the BA resources and read. You will find others with the same concerns and will learn much about where you may fit as a BA.

Talk. Discuss. Elicit information from other business analysts. Ask them what they do. And not just those in your department or specific division. Reach out across the organization and see what others are doing. You may find that the work others are doing is exactly what you've been looking for - or perhaps not. Whether you find a place where you fit, or not, at least you know what is the current landscape.

And then, try it. Try doing the work and see how it fits you. When you talk to the BA leaders in your organization ask them to give you some practice work - a case study, if you will - that you can take and run with. I have always found other business analysts eager to help their colleagues, without exception; I am certain you will find them willing to provide guidance. Ask them for a sample project and write the requirements, draw the business process models and activity diagrams; take it upon yourself to feel what the work is like. Perhaps you'll find the work dull and unsatisfying. Or, you may find it challenging and enjoyable (yes, enjoyable).

After all, it is up to you. It is up to you to find out all you can about the BA path - take advantage of the resources, talk to others in the field, learn from them, and try on the work so that when you have that next career discussion with your manager it is one that will lead you in a direction in which you will be glad to travel.

Upside down Procedures and Processes

Mike Cunningham — Wed, 27 Jul 2011 12:00:00 GMT

Are we looking at it all wrong?

Do you ever get the feeling that you are seeing something very different than the other guy? I don’t just mean the glass half full/empty outlook on life, but fundamentally are we looking at things the wrong way?

I sometimes get that feeling when dealing with projects that involve processes, and all my projects are about processes! Take the following scenario, the stakeholder or client has a problem; they know they need to improve some processes in the organization, but are not sure exactly where to begin.

As the designated Agent of Change we provide them with guidance to determine goals and objectives to scope out the next steps. For example:

· Need to document existing processes accurately

· Train existing staff how to follow these processes

· Be able to standardize the process for quality and efficiency

Before I continue, let’s go back in time …

Back to the Future

In 1770, James Watt pioneered the use of drawn-to-scale engineering plans for the manufacture and installation of industrial products1[. These were used to assist in the successful deployment of his products; steam engines for factories driving the industrial revolution. Over time these plans evolved from crude drawings to assist an experienced engineer to more detailed plans that were created by a junior draftsman. This was the forerunner of today’s Computer Aided Design ]2[ world. Detailed, precise instructions permitted products to be manufactured without the need for hugely skilled labor, and a bridge was created between design and production engineering.

In many ways the Subject Matter Expert/Project Manager takes the same role today as those early engineers. Understanding in detail what needs to be done, and translating these complex processes by way of underlying skills, experience and well established methodologies.

The time may be right to go back and look at a different way of doing things; one that may change industry again.

Looking at the pie instead of the ingredients?

When an expert looks at a problem they often want to show off their skills. Look at me I am smart, indispensible, letters after my name, better than you … got the idea. Now all project managers are not this way, but there is a tendency to want to show off our skills versus others in the project.

One way this happens is we often/always start looking at process FIRST. Because we are good at seeing the big picture, grasping the complex, overanalyzing the simple; so we habitually start with the complete process.

As a result we are often way ahead of where the client/stakeholder is in the project. Being ahead a few steps is probably OK; being so far ahead they can’t see your dust creates distance, misunderstanding and communication problems. They may not feel that you are on the same wavelength, and we all know where that leads. We don’t want to go there.

Start with the tasks, not the process.

Recently, I have been examining this problem with some precision. I know Business Process Management has the word process in the middle, and is therefore important. However, every process is full of tasks, activities and decisions. The client/stakeholder may not yet see how all these tasks are intertwined to make up their own work processes, but they understand the basis of all processes are tasks. So why don’t we start by capturing the tasks first? Good idea!

A task centric approach has several advantages over process first. These include:

1. It’s easier to get the client/stakeholder to capture precise information about roles, ownership, guidelines, resources, timeframes, frequency etc. on a task basis

2. Once you have all the important tasks documented it’s easier to then order them for the “as is” or “current state” of operations

3. Get everyone on the same page for the process documentation project

4. Builds a base of foundation data for the project

Once this task library has been created, we can return to the process view. However now we have the details we need to build on our “Discovery” phase of the project. If you have used Excel or a similar product to capture this information, it will be easily sorted and can be then categorized for the process capture stage of the project.

Conclusions

Just as we learn the alphabet, words, sentences, grammar before creating great prose; we need to apply the same principles to our Process Management activities. Taking logical steps to breakdown the “Discovery” process into tasks and then build the jigsaw puzzle that is the process makes sense.

Given the potential for re-use of tasks in best practice models, this approach may have much merit in Process Improvement methods.

]1[ NMSI. The Production Process. May 20, 2011. http://www.ingenious.org.uk/Read/Seeing/Drawings/Theproductionprocess/.

]2[ Wikipedia. Computer-aided Design. May 20, 2011. http://en.wikipedia.org/wiki/Computer-aided_design.

]

Why Should We Hire You?, Part I

Seilevel — Wed, 29 Sep 2010 18:49:00 GMT

We look for the best and brightest when hiring for Requirements Analysts and Product Managers. It’s a long and difficult process with many people applying; only a fraction get through the first interview and even less are able to hang in the process as it continues. This has brought great strain to our company: as we expand we simply aren’t able to hire as very few are able to get through our arduous interview process.

Recently, we went to the University of Texas at Austin looking for interns and entry level Requirements Analysts. They asked many questions, mostly along the lines of “what does Seilevel do?”, “what would a typical day look like for me as an RA?”, “what’s the mentoring program like?”, and “what qualities do you look for in a potential new hire?”. I would like to address the last question now, to give the potential candidates out there an idea of what kind of person we look for.

Most importantly, we look for those in whom we see great potential. Can we teach and train this person? Will she be receptive? Is she able to adapt and change to the ambiguous and sometimes difficult environment? Is she smart enough to resolve tasks on her own when others are too busy to hand-hold? To get an outstanding “Yes” on all these questions is the first test to pass. When we talk to people, we want to address these questions indirectly with candidates. This means that we most likely won’t ask these questions in the form as written above, but we probe to elicit answers which give clarity to the aforementioned questions.

People are smart. Sometimes, we want to give a solution to a problem so badly that we neglect to listen to the entire problem. We look for candidates that are patient enough to listen to a whole problem before recommending a solution. As consultants, our clients look to us to solve their problems, so it’s very important that we all know how to listen. Good listening skills include maintaining good eye contact, maintaining attentive posture, and being able to summarize the problem with different words to show you understand what the issue at hand is which also uncovers underlying assumptions.

Gathering requirements includes many hours of asking probing questions to the business in order to gain a clear understanding of what the product needs to do. We want people who instinctively ask the right questions. This is a hard item to teach, so we are looking for those who have the critical thinking skills which enables them to have these types of constructive dialogues.

We want someone who works well under pressure. From school, you’re hopefully used to completing projects or papers with strict deadlines and occasionally working long hours to ensure you get that paper or project perfected. Oftentimes on a client site you will encounter strict deadlines, as each man hour over a deadline is quite costly. We’re looking for those Type-A personalities who know what it takes to get the job done well.

Many people who are Type-A and direct communicators can be considered abrasive. What’s the difference between being a direct communicator and being abrasive? We look for those who can communicate with all kinds of people without offending them, which entails being able to change how you say things to suit the recipient. In the US, if a topic is misunderstood or lost in communication, it’s the speaker’s fault, not the listener’s. We look for candidates who grasp this concept. These people can explain the same topic using different words or methods, which better suits the listener.

Prioritization is a must have. When you have a paper for English, a SWOT analysis for marketing, a business review for accounting, and a program for comp sci all due in the same month, what do you do? How do you prioritize? What comes first and why? We always have several hands pulling at our limbs, asking for time in meetings, reviews, documentation, etc. Getting it all done and ensuring client happiness is a delicate art.

My last tip for the day is to ooze confidence! Can you present in front of a room of 20 executives and the CEO? Probably not. (And it may not be a worry here, either!) However, you should be able to speak your intelligent and prepared opinion in a meeting with stakeholders. Don’t be afraid to speak up, with a caveat: as long as you know what you’re talking about. (However, you can always talk it over with another consultant if you are nervous!) As consultants, clients look towards us for answers. We need to study the issue and propose a solution, often on topics in which we may not have formal training, but our logic can trump that issue.

Many of these skills are difficult to teach someone, which is why we look for the candidate who is the right “fit”, meaning that they already possess these baseline soft skills which we can then build upon with requirements knowledge. When preparing to interview, be sure to have prepared situations that you have personally experienced which would demonstrate your capacity to fill these characteristics we look for. Look for Part II of this post next month where we will discuss critical thinking skills necessary to become part of our team.

Are you looking know someone who is? Check out our positions:

http://requirements.seilevel.com/blog/

http://www.seilevel.com/careers/

Being New 101

Seilevel — Thu, 26 Aug 2010 19:04:00 GMT

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

http://requirements.seilevel.com/blog/

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Seilevel — Thu, 10 Jun 2010 13:52:00 GMT

By Jhulgan

I used to dread hearing the question, “So what do you do for a living?” This was often usually asked by a family member or other acquaintances not familiar with the software development lifecycle, IT, or business processes in general. For business analysts, product managers, and other software requirements types, it’s difficult to give an answer without being convoluted or sounding like Tom Smykowski:

This great post expresses a similar insight beautifully, but many of us struggle with good, one-sentence responses to what it is we do everyday in simple English. I thought I would plagiarize some ideas that I’ve heard from colleagues over the years and compile them here:

“We help businesses figure out what software they need to build to solve business problems.” This is a personal favorite of mine that I stole from Marc (who posts under mtalbot on this here blog). It’s especially relevant to IT consultants/contractors. Just about everyone knows what software is, and a lot of people understand that just about every business runs on some sort of software to solve business problems.
“We help communicate the business needs of a system in a language software developers understand.” A variation of this is, “We translate from business to geek”, although I am less fond of the second version because it veers into Smykowski land.
“We make sure the right software is being developed at the right time, for the right people.” The emphasis here is on the right software. This response is nice because it allows you to segue adeptly into a discussion about business objectives.
“We help the business get the most value out of their development dollar.” This response stresses the fact that you are not just a scribe or secretary writing things down, formatting them, and delivering them to the development staff. You are helping make the tough decisions on which features to cut and which bugs to fix, and quantifying those decisions in terms of dollars and cents.
“We work with the business to find the appropriate scope of a software development project and ensure that what is built is what the business expects.” Whenever I am asked the dreaded WDYDFAL question, this is what almost immediately comes to mind. Sometimes I fill in the details of working with pictures to help model current business processes (and desired business processes).

So how about all of our readers? What answers have you come up with? Do you dodge this question altogether, or do you sound like a fumbling Smykowski? Hopefully we can all help each other find good answers to this question. After all, you never know when you’ll be in a meeting with “The Bobs” and the pressure will be on!

You can check out our other blog posts here

Exploring progressions into BA careers

Laura Brandenburg — Fri, 12 Jun 2009 21:58:00 GMT

I know. You recently read Adrian’s latest post and said: “Yes! that’s exactly what I’m looking for! I want an employer to hire me, mentor me as a new business analyst, and then let me blossom in this career.” I wholeheartedly agree with Adrian—as business analysts we need to be mentors for other potential business analysts. I was lucky enough to become a business analyst after a year and a half as a QA engineer. I worked for the first 3 months under the wing of a senior BA and then was set loose on the biggest software project the company had started to-date. I guess they trusted me.

I wish I could say these sorts of opportunities abound but the fact is they don’t. I was lucky. I was in a growing organization that supported professional development. But I was also career-minded, consistently discontent, and always looking to improve something somewhere. I was not a “tell me what to do and I’ll do it employee”, I was a “why can’t I do that?” employee. I faced barriers, but eventually I managed to earn the responsibilities I wanted and work my way a bit up the career ladder.

In recent months, I’ve had the opportunity to hear the stories of many business analysts about how they started their business analyst careers. The stories varied but had a common theme: one step at a time. Career progressions often involved incorporating some business analyst responsibilities into their day-to-day role. Some became “BAs” without a real knowledge of what that meant or that a profession existed. Others were more like me and took a flying leap but often within the same company and with a network of support. A few managed to transition careers and companies in the same job change by selling their "BA" experiences. Darn impressive.

Regretfully, I’m not in a position to hire you, but I am looking to help on the mentoring front, starting with publishing a “how to” guide based on what I’ve learned from people who’ve successfully made the transition in this environment. We are a profession that favors experience. It can be tricky to accumulate but with a little persistance and some proper guidance you can break into this profession. Take a sneak peak to learn a bit more about How to Start a Business Analyst Career and leave your email for a special discount when the book is published in the next month.

About the author:

Laura Brandau is an independent business analyst consultant and hosts Bridging the Gap between Business and IT, a blog for business analysts about solving business problems.

3 Guaranteed ways to become a better BA

Craig Brown — Fri, 30 Jan 2009 11:22:00 GMT

In recent years I have done three things which have really ‘ramped up’ my performance at work.

In my readings online, in books and journals I have learned that there is serious researched evidence that these three things are possible some of the best ways to improve your skills and ability at work (particularly in a thinking job like ours.)

These three things are relatively cheap, the tools are only a click or two away right now and only take a small amount of time on an ongoing basis.

And I am going to tell you what they are for free.

But before I do I have to warn you that most of you won’t be able to achieve this cheap and easy path to career success.

Most of you (research suggests over 95% of you) simply won’t have the motivation and desire to take the first step. Why is that? Probably because complacency and inertia are powerful forces.

I have a close friend who is both very smart and creative. But he has a lousy McJob which bores and frustrates him (as well as not paying very much.) But no matter how much I try to convince him to use his smarts, charm and wit to move onto something more rewarding he simply refuses to budge, following the patters and routines he has for years. That’s a shame for him. And possibly it’s also a shame for you.

The good news is that you are reading this.

To have gone to ModernAnalyst.com and sought out information on how to improve your career puts you in that 5% of people who really are going to try to do better.

But five minutes browsing does not make you a top-gun BA. You’ll need to make a personal commitment to yourself; to change and to do the activities it takes to change.

Are you up for it?

Great! Keep reading.

These three things are all based on research from psychology and neuroscience, as well as being observations that managers and trainers have had over the last few years (decades?)

They are based upon a few principles that you are probably already familiar with.

We learn better in groups
Public speaking is scary because we don’t want to look silly
Teaching is the best form of learning

Do these phrases ring true with you? If not, maybe take an hour or two to go research these ideas online.

Or you can quit now. Your choice.

If you are still with me, I’m ready to tell you my three very special secrets to mastery of the BA profession, and then explain briefly to you how each one will help.

Participate actively on forums like Modern Analyst & Sign up to a few message groups in your field
Start your won blog (or blog here at ModernAnalyst) and do it on a regular basis
Find someone to mentor or coach

Stop for a moment and reflect on these recommendations.

Do you feel vague hints of “yes that‘s a good idea, but how do I start?”

Fine. We can work with that.

Let me explain a bit further.

1. Participate

Participating with groups such as Modern Analyst (and maybe a local or regional BA community) expands your horizons and introduces you to new ways of thinking.

Also discussing ideas means you learn from the conversation. And by that I don’t mean you turn up and read/listen. I mean you participate. Put up straw man ideas for discussion, or ask questions if you don’t have a strong opinion on a topic.

At the very least you have one question you want to know the answer to. “How can I best tackle tomorrow’s work activity?”

Ask this one a few times and you’ll be amazed at how much more you’ll want to discuss.

2. Blog

Blogging achieves some of the benefits of community participation, but develops other skills also. Forums and meetings are conversations where ideas are exchanged. Blogs tend to be more one way messages. You speak to an unknown (at first) audience.

This teaches you to write well. You get concise and learn to structure your thoughts in a way that is digestible for your audience. (Erm, yes this is a long post.)

As a BA your job is all about good written and verbal communication. This is a massive opportunity for you. Don’t waste your time.

Go straight to google’s blogger, to ModernAnalysts Blog home page, or to any of the other free blogging tools out there and sign up today.

Make your first post before you go to bed tonight. And then make a commitment to post at least once a week for 3 months.

If you are stuck for a first-post topic try the theme of “What did I learn this week?” Everyone wants to hear Lesson Learned. Especially me.

While you are at it you can link back to my blog at BetterProjects (here) and I’ll tell my share of the BA world about your new blog.

3. Mentor or Coach

As I said above, teaching is a great way of learning. Coaching and mentoring also gets you to focus on the people side of the business, and to hone your ‘people change’ skills.

Additionally, by sharing your knowledge around you help your personal ‘professional community’ get stronger. And you get the feel-good rush of helping someone. And the list goes on.

So, are you in?

I hope so.

Craig Brown

Better Projects